Usage

User configures endpoint call processing details in the Call Transformation tab for the circuit breaker adapter.
Both Pre-processing and Post-processing must be configured for the circuit breaker to function.

Pre-processing determines whether the call should proceed to the backend, and Post-processing updates the circuit breaker metrics based on the backend response. Disabling either results in erratic, incorrect behavior from the adapter. Therefore, both must be enabled and provided with the correct inputs.

Circuit Breaker Tuning Profiles

Choosing the right values depends on your backend's volume and stability. Use these profile samples to set your parameters correctly.

Ideal for: Standard REST APIs that require an immediate binary decision on health.
- obs-window: 50–100
- min-calls: 10
- permit-half-open: 10
Logic: This profile uses a 1:1 recovery ratio. The circuit makes a decision the moment the 10th test call in the recovery phase finishes. It is the most efficient but has zero margin for "lost" or "timed-out" requests.

Ideal for: Production environments with occasional network instability or high-concurrency gateways.
- obs-window: 100–200
- min-calls: 20
- permit-half-open: 25
Logic: This uses a 25% Safety Buffer (20 + 5). By allowing 25 calls to reach a 20-call decision, the circuit does not get "stuck" if a few requests fail to report their status because of gateway timeouts or platform glitches.

Ideal for: Backends that require a steady stream of traffic to initialize internal caches or connection pools before achieving stability.
- obs-window: 500+
- min-calls: 50
- permit-half-open: 100
Logic: This uses a 2:1 Ratio. You allow 100 requests to flow while waiting for 50 results. This provides a steady-state behavior for the backend, ensuring it is truly healthy under moderate load before opening the window to its full obs-window capacity.

Ideal for: Mission-critical services handling 1,000+ QPS.
- obs-window: 3,000
- min-calls: 300
- permit-half-open: 350
Logic: 350 calls are allowed to ensure you can comfortably reach the 300-call decision threshold, even if some requests are slow or dropped. This represents about 1/3 of a second of traffic for a 1k QPS service.

Ideal for: Services where consistency is more important than rapid response. This prevents rapid opening and closing of the circuit.
- obs-window: 5,000
- min-calls: 500
- permit-half-open: 520
Logic: This is a conservative profile. It requires 500 calls to make a decision, effectively ignoring transient spikes.

When your obs-window is large, try these recommended ratios to keep your settings proportional:

Parameter	Rationale
`min-calls = obs-window * (0.10 or higher)`	Setting `min-calls` below 10% in high-volume environments often results in "False Tripping" during minor network instability.
`obs-window >= min-calls`	Setting the `obs-window` higher than `min-calls` ensures that circuit failure or success calculations are done at the end of the `obs-window`. If `min-calls` exceeds `obs-window`, the circuit breaker waits for `min-calls` to complete before calculating the error or the slow call percentage.

Parameter	Rationale
`permit-half-open` (Average requests per second)	In high-volume systems, your "test" phase should represent roughly 1 second of real traffic. If you handle 100 QPS, setting `permit-half-open` to 100 gives you a highly accurate health check in a single second.
`permit-half-open >= min-calls` (To avoid deadlock in half-open)	Setting `permit-half-open` to equal or greater than `min-calls` ensures that the circuit breaker has enough calls in the half-open state to make a decision to move to closed and not get stuck in half-open deadlock.